Peter Popov <pet### [at] usanet> wrote...
> : strict variable types

I think that the non-programmers might balk at this.  I like the way that
renderman handles this by linking in to existing languages and thus only
providing core functionality instead of syntax.  However, for good or bad,
POV is not currently heading in that direction.

A minimal amount of stricter variables might be good, but I personally lean
more towards looser variable types.  For efficiency reasons (as you pointed
out), it might be a good idea to allow the user to specify a few
smaller/faster variable types.  But careful attention would have to be paid
to making it easy to use.  Therefore, many paradigms from other programming
languages (C/C++ especially) should not be used because the are not easy to
learn and often difficult to use.  Sure, they might be easy for most of us
in _this_ group, but there will be far more non-programmers who will not
want to have to worry about what type of variable they need to use to get
the precision they want.

Therefore, I would probably just add integer types (maybe char, but most
likely not).  And I'm pretty sure I'd totally avoid any unsigned types.

> : promotion

Promotion is currently automatically done when needed.  I like that approach
better.  Sure, automatic type casting can lead to unexpected results if the
coder doesn't pay attention to what they're doing, but if there the number
of variable types is kept to a minimum, and a logical promotion sequence is
used, then this can greatly ease the task of the coder.

> : hash variables
> For example,
> Posters[155] doesn't tell much while Posters[Peter_Popov] does, and
> they mean the same to the parser.

Current POV code:

#declare Peter_Popov = 155;
#declare ABC=Posters[Peter_Popov];

Maybe what you're looking for is this:
#declare ABC=Posters["Peter_Povpov"];

> : media emission/absorption color map

I agree.

> : patterned turbulence, turbulence_map

I agree.

> : spotlight scale

I'm not quite sure how to code this, but it sounds rather useful.

> : polygonal spotlight

My first thought is to use projected_through.  Do that with an area light
and you get realistic falloff, although I realize that doing such would not
be as fast as what you are proposing.

> : better alpha channel support

I agree.

> : displacement mapping for patterns

Sounds interesting.

> : chop pieces off with bounding

Use CSG.

> : leave original textures when CSGing

Probably won't work as well as you'd expect.  But I don't want to dismiss it
without looking closely.  It is potentially a very useful idea and may not
be as difficult to implement as I am imagining.  I would definately say that
it should be a special option for backwards compatibility reasons.

> : seeded randomness for area_light and aa jitter

As mentioned by Chris, this may not be possible.

> : zero text object thickness

Sounds good for rendering speed reasons.  On the other hand, maybe a TTF
pattern would be better.  This way you could apply the TTF object to another
infinitely thin object (such as a disc) and use filter/transmit to get the
clear part.

> : on error do something useful (skip frame etc.)
>
> OK this one I admit is a bad habit I have from my BASIC years :)

Actually, your example looks quite a bit like an exception-handling block,
and I see a lot of potential usefullness in it.

> : Additional BRDF models

I totally agree.  Also, not simply _more_ BRDF models, but _better_ BRDF
models.

-Nathan

(I speak for myself and not for the POV-Team.)

Post a reply to this message